Long Term Evolution (LTE)
Third-generation mobile systems (3G) based on WCDMA radio-access technology are being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology entails introducing High-Speed Downlink Packet Access (HSDPA) and an enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA), giving a radio access technology that is highly competitive.
In order to be prepared for further increasing user demands and to be competitive against new radio access technologies, 3GPP introduced a new mobile communication system which is called Long Term Evolution (LTE). LTE is designed to meet the carrier needs for high speed data and media transport as well as high capacity voice support for the next decade. The ability to provide high bit rates is a key measure for LTE.
The work item (WI) specification on Long-Term Evolution (LTE) called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) is finalized as Release 8 (LTE Rel. 8). The LTE system represents efficient packet-based radio access and radio access networks that provide full IP-based functionalities with low latency and low cost. In LTE, scalable multiple transmission bandwidths are specified such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) based radio access was adopted because of its inherent immunity to multipath interference (MPI) due to a low symbol rate, the use of a cyclic prefix (CP) and its affinity to different transmission bandwidth arrangements. Single-carrier frequency division multiple access (SC-FDMA) based radio access was adopted in the uplink, since provisioning of wide area coverage was prioritized over improvement in the peak data rate considering the restricted transmit power of the user equipment (UE). Many key packet radio access techniques are employed including multiple-input multiple-output (MIMO) channel transmission techniques and a highly efficient control signaling structure is achieved in LTE Rel. 8/9.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2. The E-UTRAN consists of an eNodeB, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink Quality of Service (QoS), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
The eNodeBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (SGW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNodeBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming user equipments.
Component Carrier Structure in LTE (Release 8)
The downlink component carrier of a 3GPP LTE system is subdivided in the time-frequency domain in so-called subframes. In 3GPP LTE each subframe is divided into two downlink slots as shown in FIG. 3, wherein the first downlink slot comprises the control channel region (PDCCH region) within the first OFDM symbols. Each subframe consists of a give number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), wherein each OFDM symbol spans over the entire bandwidth of the component carrier. The OFDM symbols thus each consists of a number of modulation symbols transmitted on respective NRBDL×NscRB subcarriers as also shown in FIG. 4.
Assuming a multi-carrier communication system, e.g. employing OFDM, as for example used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as NsymbDL consecutive OFDM symbols in the time domain (e.g. 7 OFDM symbols) and NscRB subcarriers in the frequency domain as exemplified in FIG. 4 (e.g. 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus consists of NsymbDL×NscRB resource elements, corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see for example 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, section 6.2, available at http://www.3gpp.org and incorporated herein by reference).
One subframe consists of two slots, so that there are 14 OFDM symbols in a subframe when a so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in a subframe when a so-called “extended” CP is used. For sake of terminology, in the following the time-frequency resources equivalent to the same NscRB consecutive subcarriers spanning a full subframe is called a “resource block pair”, or equivalent “RB pair” or “PRB pair”.
The term “component carrier” refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink and optionally uplink resources. The linking between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted on the downlink resources.
Similar assumptions for the component carrier structure apply to later releases too.
Carrier Aggregation in LTE-A for Support of Wider Bandwidth
The frequency spectrum for IMT-Advanced was decided at the World Radio communication Conference 2007 (WRC-07). Although the overall frequency spectrum for IMT-Advanced was decided, the actual available frequency bandwidth is different according to each region or country. Following the decision on the available frequency spectrum outline, however, standardization of a radio interface started in the 3rd Generation Partnership Project (3GPP). At the 3GPP TSG RAN #39 meeting, the Study Item description on “Further Advancements for E-UTRA (LTE-Advanced)” was approved. The study item covers technology components to be considered for the evolution of E-UTRA, e.g. to fulfill the requirements on IMT-Advanced.
The bandwidth that the LTE-Advanced system is able to support is 100 MHz, while an LTE system can only support 20 MHz. Nowadays, the lack of radio spectrum has become a bottleneck of the development of wireless networks, and as a result it is difficult to find a spectrum band which is wide enough for the LTE-Advanced system. Consequently, it is urgent to find a way to gain a wider radio spectrum band, wherein a possible answer is the carrier aggregation functionality.
In carrier aggregation, two or more component carriers (component carriers) are aggregated in order to support wider transmission bandwidths up to 100 MHz. Several cells in the LTE system are aggregated into one wider channel in the LTE-Advanced system which is wide enough for 100 MHz even though these cells in LTE are in different frequency bands.
All component carriers can be configured to be LTE Rel. 8/9 compatible, at least when the aggregated numbers of component carriers in the uplink and the downlink are the same. Not all component carriers aggregated by a user equipment may necessarily be Rel. 8/9 compatible. Existing mechanism (e.g. barring) may be used to avoid Rel-8/9 user equipments to camp on a component carrier.
A user equipment may simultaneously receive or transmit one or multiple component carriers (corresponding to multiple serving cells) depending on its capabilities. A LTE-A Rel. 10 user equipment with reception and/or transmission capabilities for carrier aggregation can simultaneously receive and/or transmit on multiple serving cells, whereas an LTE Rel. 8/9 user equipment can receive and transmit on a single serving cell only, provided that the structure of the component carrier follows the Rel. 8/9 specifications.
Carrier aggregation is supported for both contiguous and non-contiguous component carriers with each component carrier limited to a maximum of 110 Resource Blocks in the frequency domain using the 3GPP LTE (Release 8/9) numerology.
It is possible to configure a 3GPP LTE-A (Release 10) compatible user equipment to aggregate a different number of component carriers originating from the same eNodeB (base station) and of possibly different bandwidths in the uplink and the downlink. The number of downlink component carriers that can be configured depends on the downlink aggregation capability of the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. It may not be possible to configure a mobile terminal with more uplink component carriers than downlink component carriers.
In a typical TDD deployment, the number of component carriers and the bandwidth of each component carrier in uplink and downlink is the same. Component carriers originating from the same eNodeB need not to provide the same coverage.
The spacing between centre frequencies of contiguously aggregated component carriers shall be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of 3GPP LTE (Release 8/9) and at the same time preserve orthogonality of the subcarriers with 15 kHz spacing. Depending on the aggregation scenario, the n×300 kHz spacing can be facilitated by insertion of a low number of unused subcarriers between contiguous component carriers.
The nature of the aggregation of multiple carriers is only exposed up to the MAC layer. For both uplink and downlink there is one HARQ entity required in MAC for each aggregated component carrier. There is (in the absence of SU-MIMO for uplink) at most one transport block per component carrier. A transport block and its potential HARQ retransmissions need to be mapped on the same component carrier.
The Layer 2 structure with activated carrier aggregation is shown in FIG. 5 and FIG. 6 for the downlink and uplink respectively.
When carrier aggregation is configured, the mobile terminal only has one RRC connection with the network. At RRC connection establishment/re-establishment, one cell provides the security input (one ECGI, one PCI and one ARFCN) and the non-access stratum mobility information (e.g. TAI) similarly as in LTE Rel. 8/9. After RRC connection establishment/re-establishment, the component carrier corresponding to that cell is referred to as the downlink Primary Cell (PCell). There is always one and only one downlink PCell (DL PCell) and one uplink PCell (UL PCell) configured per user equipment in connected state. Within the configured set of component carriers, other cells are referred to as Secondary Cells (SCells); with carriers of the SCell being the Downlink Secondary Component Carrier (DL SCC) and Uplink Secondary Component Carrier (UL SCC). The characteristics of the downlink and uplink PCell are:                1. For each SCell the usage of uplink resources by the UE, in addition to the downlink ones is configurable; the number of DL SCCs configured is therefore always larger or equal to the number of UL SCCs, and no SCell can be configured for usage of uplink resources only        2. The uplink PCell is used for transmission of Layer 1 uplink control information        3. The downlink PCell cannot be de-activated, unlike SCells        4. From UE perspective, each uplink resource only belongs to one serving cell        5. The number of serving cells that can be configured depends on the aggregation capability of the UE        6. Re-establishment is triggered when the downlink PCell experiences Rayleigh fading (RLF), not when downlink SCells experience RLF        7. The downlink PCell cell can change with handover (i.e. with security key change and RACH procedure)        8. Non-access stratum information is taken from the downlink PCell        9. PCell can only be changed with handover procedure (i.e. with security key change and RACH procedure)        10. PCell is used for transmission of PUCCH        
The configuration and reconfiguration of component carriers can be performed by RRC. Activation and deactivation is done via MAC control elements. At intra-LTE handover, RRC can also add, remove, or reconfigure SCells for usage in the target cell. When adding a new SCell, dedicated RRC signaling is used for sending the system information of the SCell, the information being necessary for transmission/reception (similarly as in Rel-8/9 for handover).
When a user equipment is configured with carrier aggregation there is one pair of uplink and downlink component carriers that is always active. The downlink component carrier of that pair might be also referred to as ‘DL anchor carrier’. Same applies also for the uplink. When carrier aggregation is configured, a user equipment may be scheduled over multiple component carriers simultaneously but at most one random access procedure shall be ongoing at any time. Cross-carrier scheduling allows the PDCCH of a component carrier to schedule resources on another component carrier. For this purpose a component carrier identification field is introduced in the respective DCI formats, called CIF.
A linking between uplink and downlink component carriers allows identifying the uplink component carrier for which the grant applies when there is no-cross-carrier scheduling. The linkage of downlink component carriers to uplink component carrier does not necessarily need to be one to one. In other words, more than one downlink component carrier can link to the same uplink component carrier. At the same time, a downlink component carrier can only link to one uplink component carrier.
General Overview of the OSI Layer
FIG. 7 provides a brief overview on the OSI model on which the further discussion of the LTE architecture is based and based on which also the invention will be discussed herein.
The Open Systems Interconnection Reference Model (OSI Model or OSI Reference Model) is a layered abstract description for communication and computer network protocol design. The OSI model divides the functions of a system into a series of layers. Each layer has the property that it only uses the functions of the layer below, and only exports functionality to the layer above. A system that implements protocol behavior consisting of a series of these layers is known as a ‘protocol stack’ or ‘stack’. Its main feature is in the junction between layers which dictates the specifications on how one layer interacts with another. This means that a layer written by one manufacturer can operate with a layer from another. For our purpose, only the first three layers will be described in more detail below.
The physical layer or layer 1's main purpose is the transfer of information (bits) over a specific physical medium (e.g. coaxial cables, twisted pairs, optical fibers, air interface, etc.). It converts or modulates data into signals (or symbols) that are transmitted over a communication channel.
The purpose of the data link layer (or Layer 2) is to shape the information flow in a way compatible with the specific physical layer by breaking up the input data into data frames (Segmentation And Re-assembly (SAR) functions). Furthermore, it may detect and correct potential transmission errors by requesting a retransmission of a lost frame. It typically provides an addressing mechanism and may offer flow control algorithms in order to align the data rate with the receiver capacity. If a shared medium is concurrently used by multiple transmitters and receivers, the data link layer typically offers mechanisms to regulate and control access to the physical medium.
As there are numerous functions offered by the data link layer, the data link layer is often subdivided into sublayers (e.g. RLC and MAC sublayers in UMTS). Typical examples of Layer 2 protocols are PPP/HDLC, ATM, frame relay for fixed line networks and RLC, LLC or MAC for wireless systems. More detailed information on the sublayers PDCP, RLC and MAC of layer 2 is given later.
The network layer or Layer 3 provides the functional and procedural means for transferring variable length packets from a source to a destination via one or more networks while maintaining the quality of service requested by the transport layer. Typically, the network layer's main purposes are inter alia to perform network routing, network fragmentation and congestion control functions. The main examples of network layer protocols are the IP Internet Protocol or X.25.
With respect to Layers 4 to 7 it should be noted that depending on the application and service it is sometimes difficult to attribute an application or service to a specific layer of the OSI model since applications and services operating above Layer 3 often implement a variety of functions that are to be attributed to different layers of the OSI model. Therefore, especially in TCP(UDP)/IP based networks, Layer 4 and above is sometimes combined and forms a so-called “application layer”.
Layer Services and Data Exchange
In the following the terms service data unit (SDU) and protocol data unit (PDU) as used herein are defined in connection with FIG. 8. In order to formally describe in a generic way the exchange of packets between layers in the OSI model, SDU and PDU entities have been introduced. An SDU is a unit of information (data/information block) transmitted from a protocol at the layer N+1 that requests a service from a protocol located at layer N via a so-called service access point (SAP). A PDU is a unit of information exchanged between peer processes at the transmitter and at the receiver of the same protocol located at the same layer N.
A PDU is generally formed by a payload part consisting of the processed version of the received SDU(s) preceded by a layer N specific header and optionally terminated by a trailer. Since there is no direct physical connection (except for Layer 1) between these peer processes, a PDU is forwarded to the layer N−1 for processing. Therefore, a layer N PDU is from a layer N−1 point of view an SDU.
LTE Layer 2—User Plane Protocol Stack
The LTE layer 2 user-plane protocol stack is composed of three sublayers as shown in FIG. 9, PDCP, RLC and MAC. As explained before, at the transmitting side, each layer receives a SDU from a higher layer for which the layer provides a service and outputs a PDU to the layer below. The RLC layer receives packets from the PDCP layer. These packets are called PDCP PDUs from a PDCP point of view and represent RLC SDUs from an RLC point of view. The RLC layer creates packets which are provided to the layer below, i.e. the MAC layer. The packets provided by RLC to the MAC layer are RLC PDUs from an RLC point of view and MAC SDUs from a MAC point of view.
At the receiving side, the process is reversed, with each layer passing SDUs up to the layer above, where they are received as PDUs.
While the physical layer essentially provides a bitpipe, protected by turbo-coding and a cyclic redundancy check (CRC), the link-layer protocols enhance the service to upper layers by increased reliability, security and integrity. In addition, the link layer is responsible for the multi-user medium access and scheduling. One of the main challenges for the LTE link-layer design is to provide the required reliability levels and delays for Internet Protocol (IP) data flows with their wide range of different services and data rates. In particular, the protocol over-head must scale. For example, it is widely assumed that voice over IP (VoIP) flows can tolerate delays on the order of 100 ms and packet losses of up to 1 percent. On the other hand, it is well-known that TCP file downloads perform better over links with low bandwidth-delay products. Consequently, downloads at very high data rates (e.g., 100 Mb/s) require even lower delays and, in addition, are more sensitive to IP packet losses than VoIP traffic.
Overall, this is achieved by the three sublayers of the LTE link layer that are partly intertwined.
The Packet Data Convergence Protocol (PDCP) sublayer is responsible mainly for IP header compression and ciphering. In addition, it supports lossless mobility in case of inter-eNB handovers and provides integrity protection to higher layer-control protocols.
The radio link control (RLC) sublayer comprises mainly ARQ functionality and supports data segmentation and concatenation. The latter two minimize the protocol overhead independent of the data rate.
Finally, the medium access control (MAC) sublayer provides HARQ and is responsible for the functionality that is required for medium access, such as scheduling operation and random access. FIG. 10 exemplary depicts the data flow of an IP packet through the link-layer protocols down to the physical layer. The figure shows that each protocol sublayer adds its own protocol header to the data units.
Packet Data Convergence Protocol (PDCP)
The PDCP layer processes Radio Resource Control (RRC) messages in the control plane and IP packets in the user plane. Depending on the radio bearer, the main functions of the PDCP layer are:                header compression and decompression for user plane data        Security functions:                    Ciphering and deciphering for user plane and control plane data            Integrity protection and verification for control plane data                        Handover support functions:                    In-sequence delivery and reordering of PDUs for the layer above at handover;            Lossless handover for user plane data mapped on RLC Acknowledged Mode (AM)                        Discard for user plane data due to timeout.        
The PDCP layer manages data streams in the user plane, as well as in the control plane, only for the radio bearers using either a Dedicated Control Channel (DCCH) or a Dedicated Transport Channel (DTCH). The architecture of the PDCP layer differs for user plane data and control plane data, as shown in FIGS. 11 and 12. Two different types of PDCP PDUs are defined in LTE: PDCP Data PDUs and PDCP Control PDUs. PDCP Data PDUs are used for both control and user plane data. PDCP Control PDUs are only used to transport the feedback information for header compression, and for PDCP status reports which are used in case of handover and hence are only used within the user plane.
Due to the low relevance to the invention, the functions Header Compression, Security and Handover are not explained in detail; details in said respect can be found in LTE—The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Edited by: Stefania Sesia, Issam Toufik, Matther Baker, Second Edition, ISBN 978-0-470-66025-6, Chapters 4.2.2, 4.2.3 and 4.2.4 incorporated herein by reference.
On the other hand, the discarding of data packets will be explained in the following in detail. The PDCP layer in general and discarding in the PDCP layer in particular is defined in 3GPP TS 36.323 v11.2.0 (2013-03), incorporated herein by reference.
In the context of this invention the term “discarding” shall not be understood in its strictest sense as deleting the packet right away, but shall more broadly cover the concept of indicating the packet (e.g. the PDCP PDU/SDUs) as not being necessary anymore and thus should to be deleted. The technical standard leaves open at which particular point in time the PDCP PDU/SDUs are actually deleted (it only specifies when they shall be discarded), since the buffer management is mostly left to the technical implementation. Therefore, after a packet is “discarded”, it may be that according to one technical implementation the packet is deleted immediately or according to another technical implementation that the buffer is emptied periodically by deleting those packets that are indicated as discarded. Typically, the data rate that is available on the radio interface is smaller than the data rate available on the network interfaces. Thus, when the data rate of a given service is higher than the data rate provided by the LTE radio interface, buffering in the UE and in the eNodeB is the result. This buffering allows the scheduler in the MAC layer some freedom to vary the instantaneous data rate at the physical layer in order to adapt to the current radio channel conditions. Thanks to the buffering, the variations in the instantaneous data rate are then seen by the application only as some jitter in the transfer delay.
However, when the data rate provided by the application exceeds the data rate provided by the radio interface for a long period of time, large amounts of buffered data can result. This may lead to a large loss of data at handover if lossless handover is not applies to the bearer, or to an excessive delay for real time applications.
In order to e.g. prevent excessive delay, a discard function is included in the PDCP layer for LTE. This discard function is based on a timer, where for each PDCP SDU received from the higher layers in the transmitter a timer (“discardTimer”) is started.
Also, the PDCP layer continues generating the PDCP PDU out of the higher layer PDCP SDU, and once generated, forwards the generated PDCP PDU to the lower layer, RLC.
The standard TS 36.323 Chapter 5.4 describes that, when the timer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by the PDCP status report, the UE shall discard the PDCP SDU along with the corresponding PDCP PDU.
The PDCP status report is sent in connection with a handover of the mobile station from a base station to another base station. Although not explicitly specified by the 3GPP standardization and thus left for technical implementation, the PDCP PDU and SDU shall also be deleted by the PDCP layer after the PDCP PDU was successfully forwarded to the UE; in particular, after the PDCP PDU was forwarded to the RLC and successful delivered to the UE by the RLC (more general, and not in connection with a handover; which can be indicated by the RLC layer), but before the expiry of the timer. In that case also the timer which is specific to the PDCP SDU (and thus to the PDCP PDU) shall be aborted/deleted/stopped.
However, when the timer expires for a PDCP SDU, a successful delivery of the PDCP SDU to the UE could not yet be achieved. As stated by the standard TS 36.323, the PDCP layer discards the PDCP SDU and PDCP PDU and indicates the discard for the particular PDCP PDU to the lower layer, RLC.
When indicated from upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity (see later chapter) shall discard the indicated RLC SDU if no segment of the RLC SDU has been mapped to a RLC data PDU yet (see 3GPP TS 36.322 Chapter 5.3).
The PDCP layer discards the packets based on the “discardTimer”, which can be for example set according to the certain delay requirements given by the required QoS of the radio bearer. For instance, a packet does not need to be transmitted in case it is too late for the service. This discard mechanism can thus prevent excessive delay and queuing in the transmitter.
The peer PDCP entity is not informed since RLC layer takes care of the in-sequence delivery. The peer PDCP entity does not wait for any PDCP packet that is not received.
The discard mechanism of the PDCP layer is illustrated exemplary in FIG. 13, which is a simplified flow diagram for the processing of a PDCP SDU and the corresponding discard of the PDCP SDU and PDCP PDU based on the discardTimer as defined by 3GPP. As apparent therefrom, the deletion of successfully-delivered PDCP PDU/SDUs is omitted from the figure, since this is only of low relevance to the discard mechanism which is the focus of the this invention.
PDCP PDUs for user plane data comprise a “D/C” field in order to distinguish Data and Control PDUs, the formats of which are shown in FIGS. 14 and 15 respectively. PDCP Data PDUs comprise a 7- or 12-bit sequence number (SN). PDCP Data PDUs for user plane data contain either an uncompressed (if header compression is not used) or a compressed IP packet. PDCP Data PDUs for control plane data (e.g. RRC signalling) comprise a MAC-I field of 32-bit length for integrity protection. PDCP Data PDUs for control plane data contain one complete RRC message.
PDCP Control PDUs are used by PDCP entities handling user plane data. There are two types of PDCP Control PDUs, distinguished by the PDU Type field in the PDCP header. PDCP Control PDUs carry wither PDCP “Status Reports” for the case of lossless handover, or ROHC feedback created by the ROHC header compression protocol. PDCP Control PDUs carrying ROHC feedback are used for user plane radio bearers mapped on either RLC UM or RLC AM, while PDCP control PDUs carrying PDCP Status Reports are used only for user plane radio bearers mapped on RLC AM.
A PDCP Control PDU carrying a PDCP Status Report for the case of lossless handover is used to prevent the retransmission of already-correctly-received PDCP SDUs, and also to request retransmission of PDCP SDUs which were correctly received but for which header decompression failed. This PDCP Control PDU contains a bitmap indicating which PDCP SDUs need to be retransmitted and a reference SN, the First Missing SDU (FMS). In the case that all PDCP SDUs have been received in sequence, this field indicates the next expected SN, and no bitmap is included.
Radio Link Control (RLC)
The RLC layer is located between the PDCP layer (the “upper” layer, from RLC perspective) and the MAC layer (the “lower” layer”, from RLC perspective). It communicates with the PDCP layer through a Service Access Point (SAP) and with the MAC layer via logical channels. The RLC layer reformats PDCP PDUs (i.e. RLC SDUs) in order to fit them into the size indicated by the MAC layer; i.e., the RLC transmitter segments and/or concatenates the PDCP PDUs, and the RLC receiver reassembles the RLC PDUs to reconstruct the PDCP PDUs. In addition, the RLC reorders the RLC PDUs if they are received out of sequence due to the HARQ operation performed in the MAC layer.
The functions of the RLC layer are performed by “RLC entities”. An RLC entity is configured in one of three data transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). IN AM, special functions are defined to support retransmission.
The main functions of UM RLC can be summarized as follows: Segmentation and concatenation of RLC SDUs (i.e. PDCP PDUs); reordering of RLC PDUs; Duplicate detection of RLC SDUs; Reassembly of RLC SDUs.
The main functions of AM RLC can be summarized as follows: Retransmission of RLC Data PDUs; Re-Segmentation of retransmitted RLC Data PDUs; Polling; Status Rreporting; Status Prohibit.
More information on RLC is given by Chapter 4.3.1 of LTE—The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Edited by: Stefania Sesia, Issam Toufik, Matther Baker, Second Edition, ISBN 978-0-470-66025-6, incorporated herein by reference.
Segmentation and concatenation is an important function of the UM and AM RLC entities. The transmitting UM/AM RLC entity performs segmentation and/or concatenation on RLC SDUs received from upper layers, to form RLC PDUs. The size of the RLC PDU at each transmission opportunity is decided and notified by the MAC layer depending on the radio channel conditions and the available transmission resources; therefore, the size of each transmitted RLC PDU can be different. The transmitting UM/AM RLC entity includes RLC SDUs into an RLC PDU in the order in which the y arrive at the UM/AM RLC entity. Therefore, a single RLC PDU can contain RLC SDUs or segments of RLC SDUs.
After segmentation and/or concatenation of RLC SDUs, the transmitting UM/AM RLC entity includes relevant RLC headers in the RLC PDU to indicate the sequence number of the RLC PDU, and additionally the size and boundary of each included RLC SDU or RLC SDU segment. It should be noted that the RLC sequence number is independent from the sequence number added by the PDCP.
As already mentioned above, when indicated from the upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity shall discard the indicated RLC SDU if no segment of the RLC SDU has been mapped to a RLC data PDU yet (see 3GPP TS 36.322 Chapter 5.3). The decision as to whether the RLC SDU was already “mapped to a RLC data PDU” can be regarded as meaning:                Received at the RLC layer, and        Relevant Header information added (and submitted/ready-to-be-submitted to lower layer)Small Cells        
Explosive demands for mobile data are driving changes in how mobile operators will need to respond to the challenging requirements of higher capacity and improved Quality of user Experience (QoE). Currently, fourth generation wireless access systems using Long Term Evolution (LTE) are being deployed by many operators worldwide in order to offer faster access with lower latency and more efficiency than 3G/3.5G system. Nevertheless, the anticipated future traffic growth is so tremendous that there is a vastly increased need for further network densification to handle the capacity requirements, particularly in high traffic areas (hot spot areas) that generate the highest volume of traffic. Network densification—increasing the number of network nodes, thereby bringing them physically closer to the user terminals—is a key to improving traffic capacity and extending the achievable user-data rates of a wireless communication system.
In addition to straightforward densification of a macro deployment, network densification can be achieved by the deployment of complementary low-power nodes respectively small cells under the coverage of an existing macro-node layer. In such a heterogeneous deployment, the low-power nodes provide very high traffic capacity and very high user throughput locally, for example in indoor and outdoor hotspot positions. Meanwhile, the macro layer ensures service availability and QoE over the entire coverage area. In other words, the layer containing the low-power nodes can also be referred to as providing local-area access, in contrast to the wide-area-covering macro layer.
The installation of low-power nodes respectively small cells as well as heterogeneous deployments has been possible since the first release of LTE. In this regard, a number of solutions have been specified in recent releases of LTE (i.e., Release-10/11). More specifically, these releases introduced additional tools to handle inter-layer interference in heterogeneous deployments. In order to further optimize performance and provide cost/energy-efficient operation, small cells require further enhancements and in many cases need to interact with or complement existing macro cells. Such solutions will be investigated during the further evolution of LTE—Release 12 and beyond. In particular further enhancements related to low-power nodes and heterogeneous deployments will be considered under the umbrella of the new Rel-12 study item (SI) “Study on Small Cell Enhancements for E-UTRA and E-UTRAN”. Some of these activities will focus on achieving an even higher degree of interworking between the macro and low-power layers, including different forms of macro assistance to the low-power layer and dual-layer connectivity. Dual connectivity implies that the device has simultaneous connections to both macro and low-power layers.
Some deployment scenarios assumed in this study item on small cell enhancements will be discussed below. In the following scenarios, the backhaul technologies categorized as non-ideal backhaul in TR 36.932 are assumed.
Both ideal backhaul (i.e., very high throughput and very low latency backhaul such as dedicated point-to-point connection using optical fiber) and non-ideal backhaul (i.e., typical backhaul widely used in the market such as xDSL, microwave, and other backhauls like relaying) should be studied. The performance-cost trade-off should be taken into account.
A categorization of non-ideal backhaul based on operator inputs is listed in the table below:
Backhaul TechnologyLatency (One way)ThroughputPriority (1 is the highest)Fiber Access 110-30ms10M-10Gbps1Fiber Access 25-1ms100-1000Mbps2Fiber Access 32-5ms50M-10Gbps1DSL Access15-60ms10-100Mbps1Cable25-35ms10-100Mbps2Wireless Backhaul5-35ms10 Mbps-100 Mbps typical,1maybe up to Gbps range
Fiber access which can be used to deploy Remote Radio Heads (RRHs) is not assumed in this study. HeNBs are not precluded, but not distinguished from Pico eNBs in terms of deployment scenarios and challenges even though the transmission power of HeNBs is lower than that of Pico eNBs. The following 3 scenarios are considered.
Scenario #1 is illustrated in FIG. 16 and is the deployment scenario where macro and small cells on the same carrier frequency (intra-frequency) are connected via a non-ideal backhaul. User are distributed both for outdoor and indoor.
Scenario #2 is illustrated in FIGS. 17 and 18 and refers to a deployment scenario where macro and small cells on different carrier frequencies (inter-frequency) are connected via a non-ideal backhaul. User are distributed both for outdoor and indoor. There are essentially two different scenarios #2, referred herein as 2a and 2b, the difference being that in scenario 2b an indoor small cell deployment is considered.
Scenario #3 is illustrated in FIG. 19 and refers to a deployment scenario where only small cells on one or more carrier frequencies are connected via a non-ideal backhaul link.
Depending on the deployment scenario, different challenges/problems exist which need to be further investigated. During the study item phase such challenges have been identified for the corresponding deployment scenarios and captured in TS 36.842; more details on those challenges/problems can be found there.
In order to resolve the identified challenges which are described in section 5 of TS36.842, the following design goals are taken into account for this study in addition to the requirements specified in TR 36.932.
In terms of mobility robustness:                For UEs in RRC_CONNECTED, Mobility performance achieved by small cell deployments should be comparable with that of a macro-only network.        
In terms of increased signaling load due to frequent handover:                Any new solutions should not result in excessive increase of signaling load towards the Core Network. However, additional signaling and user plane traffic load caused by small cell enhancements should also be taken into account.        
In terms of improving per-user throughput and system capacity:                Utilising radio resources across macro and small cells in order to achieve per-user throughput and system capacity similar to ideal backhaul deployments while taking into account QoS requirements should be targeted.Dual Connectivity        
One promising solution to the problems which are currently under discussion in 3GPP RAN working groups is the so-called “dual connectivity” concept. The term “dual connectivity” is used to refer to an operation where a given UE consumes radio resources provided by at least two different network nodes connected with a non-ideal backhaul. Essentially, the UE is connected with both a macro cell (macro eNB) and small cell (secondary or small eNB). Furthermore, each eNB involved in dual connectivity for a UE may assume different roles. Those roles do not necessarily depend on the eNB's power class and can vary among UEs.
Since the study Item is currently at a very early stage, details on the dual connectivity are not decided yet. For example the architecture has not been agreed on yet. Therefore, many issues/details, e.g. protocol enhancements, are still open currently. FIG. 20 shows an exemplary architecture for dual connectivity. It should be only understood as one potential option; the invention is not limited to this specific network/protocol architecture but can be applied generally. The following assumptions on the architecture are made here:                Per bearer level decision where to serve each packet, C/U plane split                    As an example UE RRC signalling and high QoS data such as VoLTE can be served by the Macro cell, while best effort data is offloaded to the small cell.                        No coupling between bearers, so no common PDCP or RLC required between the Macro cell and small cell        Looser coordination between RAN nodes        SeNB has no connection to S-GW, i.e. packets are forwarded by MeNB        Small Cell is transparent to CN.        
Regarding the last two bullet points, it should be noted that it's also possible that SeNB is connected directly with the S-GW, i.e. S1-U is between S-GW and SeNB. Essentially there are three different options w.r.t the bearer mapping/splitting:                Option 1: S1-U also terminates in SeNB; depicted in FIG. 21a         Option 2: S1-U terminates in MeNB, no bearer split in RAN; depicted in FIG. 21b         Option 3: S1-U terminates in MeNB, bearer split in RAN; depicted in FIG. 21c         
FIG. 21a-c depict those three options taking the downlink direction for the U-Plane data as an example. For explanation purpose, option 2 is mainly assumed for this application, and is the basis for FIG. 20 too.
User Plane Architecture for Small Cell Enhancement
In addition to the discussion on the splitting of the U-plane data as depicted in FIG. 21a-c, different alternatives have been discussed for the user plane architecture too.
A common understanding is that, when the S1-U interface terminates at the MeNB, the protocol stack in the SeNB must at least support RLC (re-)segmentation. This is due to the fact that RLC (re-)segmentation is an operation that is tightly coupled to the physical interface (e.g. MAC layer indicating size of the RLC PDU, see above), and when a non-ideal backhaul is used, RLC (re-)segmentation must take place in the same node as the one transmitting the RLC PDUs.
Based on this assumption, four families for the user plane alternatives are distinguished in the on-going discussion.                A. Independent PDCPs: this option terminates the currently defined air-interface U-plane protocol stack completely per bearer, and is tailored to realize transmission of one EPS bearer by one node, but could also support splitting of a single EPS bearer for transmission by MeNB and SeNB with the help of an additional layer. The transmission of different bearers may still happen simultaneously from the MeNB and a SeNB.        B. Master-Slave PDCPs: this option assumes that S1-U terminates in MeNB with at least part of the PDCP layer residing in the MeNB. In case of bearer split, there is a separate and independent RLC bearer, also at UE side, per eNB configured to deliver PDCP PDUs of the PDCP bearer, terminated at the MeNB.        C. Independent RLCs: this option assumes that S1-U terminates in MeNB with the PDCP layer residing in the MeNB. In case of bearer split, there is a separate and independent RLC bearer, also at UE side, per eNB configured to deliver PDCP PDUs of the PDCP bearer, terminated at the MeNB.        D. Master-Slave RLCs: this option assumes that S1-U terminates in MeNB with the PDCP layer and part of the RLC layer residing in the MeNB. While requiring only one RLC entity in the UE for the EPS bearer, on the network side the RLC functionality is distributed between the nodes involved, with a “slave RLC” operating in the SeNB. In downlink, the slave RLC takes care of the delay-critical RLC operation needed at the SeNB: it receives from the master RLC at the MeNB readily built RLC PDUs (with Sequence Number already assigned by the master) that the master has assigned for transmission by the slave, and transmits them to the UE. The custom-fitting of these PDUs into the grants from the MAC scheduler is achieved by re-using the currently defined re-segmentation mechanism.        
Based thereon different architectures are proposed, which are illustrated in FIG. 22a-i; these are taken from the Email Discussion Report on U-Plane Alternatives, 3GPP TSG-RAN WG2 Meeting #82, R2-131621 by Nokia Siemens Networks (Rapporteur).
An overview of the main characteristics of the various alternatives illustrated in FIG. 22a-i is given in the following; where bearer split shall be understood as the ability to split a bearer over multiple eNBs. As can be seen from the figures two bearers are assumed which are indicated to come over the S1 interface.                1A: S1-U terminates in SeNB+independent PDCPs (no bearer split);        2A: S1-U terminates in MeNB+no bearer split in MeNB+independent PDCP at SeNB;        2B: S1-U terminates in MeNB+no bearer split in MeNB+master-slave PDCPs;        2C: S1-U terminates in MeNB+no bearer split in MeNB+independent RLC at SeNB;        2D: S1-U terminates in MeNB+no bearer split in MeNB+master-slave RLCs;        3A: S1-U terminates in MeNB+bearer split in MeNB+independent PDCPs for split bearers;        3B: S1-U terminates in MeNB+bearer split in MeNB+master-slave PDCPs for split bearers;        3C: S1-U terminates in MeNB+bearer split in MeNB+independent RLCs for split bearers;        3D: S1-U terminates in MeNB+bearer split in MeNB+master-slave RLCs for split bearers.        
During the discussion various advantages and drawbacks are identified for each of the above alternatives.
Shortcomings of User Plane Architecture
As explained above, the backhaul link between the MeNB and SeNB could be slow and thus cause a one-direction latency which could be high, e.g. 60 ms (see above table for the non-ideal backhaul).
Further, in some user plane architecture alternatives even the part of the Access Stratum protocol layers (e.g. PDCP, RLC, MAC) will be distributed between the MeNB and SeNB. Correspondingly, the high latency would make it impossible to share real time information between the nodes; some information might be even outdated by the time it reaches the other node.
In addition, the inter-layer/cross-layer communication would increase the interface signaling burden on the interface between the nodes (i.e. X2 interface between Macro and Small eNB). It should also be ensured that the load on this interface is not unnecessary.
In more detail, the latency introduced due to the Dual Connectivity in inter-layer/cross-layer communication can be a source of other problems, e.g. to the existing procedure of the PDCP SDU/PDU discard mechanism.
As explained in connection with FIG. 13, in the prior art the PDCP SDU discard works based on the discardTimer, upon expiry of which the corresponding PDCP SDU along with the corresponding PDCP PDU (if already generated) are discarded. If the corresponding PDCP PDU has already been submitted to the lower layer, the discard is to be indicated to the lower layer.
The PDCP discard mechanism of FIG. 13 may be applied to the scenario where the PDCP and RLC layers are distributed between the MeNB and SeNB, and in particular where the PDCP (or at least the PDCP SDU discard mechanism) is not at the SeNB; this is illustrated in FIG. 23. This is true for at least currently discussed user plane architectures of Alternatives 2C, 2D, 3C, 3D; and possibly also for Alternatives 2B and 3B, depending on how the Master-Slave PDCP layers in MeNB and SeNB are split, in particular as to whether the PDCP SDU/PDU discard functionality as discussed is located at the MeNB or the SeNB.
As can be seen from FIG. 23, it is assumed that the PDCP layer, and in particular the PDCP discard function, is located in the MeNB, whereas the RLC layer is located at the SeNB.
For data to be transmitted in the downlink from the MeNB/SeNB to the UE, the PDCP layer starts a discardTimer for each PDCP SDU it receives, and continuously checks whether the timer for the PDCP SDU expires. In addition, the PDCP layer also performs its usual function of generating a PDCP PDU out of the PDCP SDU (e.g. Header Compression, Ciphering, Integrity Protection, add PDCP header, see FIG. 11) and forwarding the PDCP PDU to the RLC layer. Upon expiry of the discardTimer for a particular PDCP SDU, the PDCP PDU and PDCP SDU shall be discarded. Furthermore, the PDCP layer in the MeNB checks whether the correspondingly generated PDCP PDU was already forwarded to the lower layer, RLC, or not. If not, no indication towards the RLC layer is necessary. If the PDCP PDU was already forwarded to the RLC (“Yes”), although the PDCP PDU and SDU in the PDCP layer are discarded, it is further necessary to instruct the RLC to discard the corresponding PDCP PDU as well. The RLC layer at the SeNB in turn checks whether it has already proceeded to map the PDCP PDU (or a segment of it) to an RLC PDU, in which case discard of the PDCP PDU in the RLC layer is no longer possible. If however the PDCP PDU was not yet processed by the RLC layer to a RLC PDU, then the PDCP PDU may be discarded in the RLC layer too.
It should be noted that the PDCP PDU is from RLC perspective an RLC SDU; this applies for most alternatives of FIG. 22. However, where the RLC layer is split between the MeNB and SeNB (see Alternatives 2D and 3D), the terminology is somewhat ambiguous, since the RLC layer in the MeNB receives the PDCP PDU, performs particular functions on it (which are not yet defined), and then forwards the resulting “packet” to the RLC layer of the SeNB. From the perspective of the RLC layer of the SeNB, it may be said that it receives an RLC PDU or an RLC SDU, depending on whether the functions of the RLC layer in the MeNB are already considered to form the RLC PDU or not. In the following description of the invention, it is assumed for illustration purposes and for simplicity only that the RLC layer at the SeNB receives an RLC SDU from the MeNB (be it from the PDCP layer or from the Master RLC layer in the MeNB); which should however not restrict the invention and scope to this terminology, the use of the terminology “RLC PDU” may be used equivalently in this connection.
As mentioned, the MeNB indicates the discard of PDCP PDU(s) to the RLC layer at the SeNB. This may result in per-packet discard information being sent on the X2-interface. Firstly, this is a waste of resources since this information needs to be carried for each PDCP PDU that may need to be discarded.
Another problem is that due to the X2-interface latency, it is possible that in the meantime, the SeNB actually started transmitting the PDCP PDU (or at least a PDCP PDU segment) i.e. forming the RLC PDU; with the result that the SeNB must complete the PDU successful transmission—which would not be necessary otherwise. Therefore, due to the possible high latency on the X2-interface, the discard functionality may not really work for downlink transmissions.